As a result of an architecture-level security analysis, a number of technical requirements are derived, which must be translated into implementation choices, e.g., countermeasures in the development, deployment, configuration, and operation phases. However, once these countermeasures are in place, it may be difficult to reconstruct their original rationale a-posteriori. Failure to establish such a link between countermeasures and the corresponding architecture-level rationale can lead to negative effects if mechanisms related to security are modified without an assessment of the impact of these modifications.
For example, the disconnection between the architectural design of an application and the implementation of the application is a well known problem in software and security engineering. Generally, the forward link (e.g., the architecture-level specifications to implementation and operational configurations) may be established at development or deployment time when the detailed security requirements stemming from the architectural analysis are translated into countermeasures. A countermeasure may be the considered the specific implementation technique to satisfy a security requirement. One example of a countermeasure may be the use of a particular software library, e.g., to apply input sanitization to all data coming from untrusted sources. This type of countermeasure may be motivated by a particular security requirement related to the integrity of incoming data.
The reverse link (e.g., from countermeasures to the security requirements) may be considered more problematic to establish and maintain. Often times, the links from the countermeasures to the security requirements are neglected, or left to ad-hoc manual, time-consuming and error-prone methods. Also, if the context where a system operates is changed, it may be difficult to trace these changes back to the architectural rationale and to assess how the changed system would impact the overall system security.